System and method for monitoring computing servers for possible unauthorized access

ABSTRACT

A system is provided that includes one or more computing servers and a processing circuit for monitoring data transactions of the computing servers. Each of the computing servers is configured to provide respective services to remote users. The processing circuit is configured to monitor data transactions of at least one of the computing servers, which is associated with a user account. A security policy of the user account includes a set of conditions that are indicative of unauthorized access when the conditions are satisfied by various characteristics of the monitored data. The processing circuit is configured to determine a threat level based on the characteristics of the data transactions and the conditions of the security policy. In response to the threat level exceeding a first threshold level indicated in the security policy of the user account, the processing circuit sends a notification to an authorized user of the user account.

FIELD OF THE INVENTION

The present disclosure relates to monitoring of computing servers.

OVERVIEW

Computing servers are increasingly being used to provide variousservices over a network including but not limited to website hosting,remote data storage, remote computing services, virtual computingenvironments, communication services (e.g., voice-over-IP (VoIP), videoconferencing, call exchange servers, packet switching, and trafficmanagement). For ease of reference, the various applications, systemsand services that may be provided by computing servers may becollectively referred to as remote services. In some applications,computing servers may use authentication mechanisms to preventunauthorized access to user data, fee-based services, or accountsettings. However, authentication mechanisms may be bypassed usingvarious computing exploits and/or social engineering techniques.

SUMMARY

Aspects of the present disclosure are directed to network applicationsthat address challenges including those discussed above, and that areapplicable to a variety of applications, devices, systems and methods.These and other aspects of the present disclosure are exemplified in anumber of implementations and applications, some of which are shown inthe figures and characterized in the claims section that follows.

According to one or more embodiments, a system is provided that includesone or more computing servers (e.g., VoIP servers) and a processingcircuit, communicatively-coupled to the computing servers, formonitoring data transactions of the computing servers. Each of thecomputing servers is configured to provide respective remote services toremote users. The processing circuit is configured to monitor datatransactions (e.g., VoIP calls) of at least one of the computing servers(e.g., a VoIP server), which is associated with a user account. Asecurity policy of the user account includes a set of conditions thatare indicative of unauthorized access when the conditions are satisfiedby various characteristics of the monitored data transaction (e.g.,frequency of data transactions, size of data transactions, filesaccessed, and/or cost of data transaction). The processing circuit isconfigured to determine a threat level based on the characteristics ofthe data transactions and the conditions of the security policy. Inresponse to the threat level exceeding a first threshold level,indicated in the security policy of the user account, the processingcircuit sends a notification to an authorized user of the user account.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be more completely understood in consideration of thefollowing detailed description of various embodiments of the inventionin connection with the accompanying drawings, in which:

FIG. 1 shows an example network architecture with a cloud-based fileserver and application server;

FIG. 2 shows an alert system configured in accordance with one or moreembodiments of the present disclosure;

FIG. 3 shows an example process for monitoring a computing server forunauthorized access in accordance with one or more embodiments of thepresent disclosure; and

FIG. 4 shows an example process for providing an alert to an authorizeduser of a computing server account based on a threat level of theunauthorized access in accordance with one or more embodiments of thepresent disclosure.

While various embodiments are amenable to various modifications andalternative forms, specifics thereof have been shown by way of examplein the drawings and will be described in detail. It should beunderstood, however, that the intention is not to limit the invention tothe particular embodiments described. On the contrary, the intention isto cover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

DETAILED DESCRIPTION

The present disclosure describes various systems and devices formonitoring computing servers and providing alerts in response todetecting possible unauthorized access. The disclosed embodiments areapplicable to various different types of computing servers including,e.g., VoIP servers, file servers, email servers, web servers, andvirtual computing services. For ease of explanation, the examples andembodiments herein are primarily described with reference to VoIPservers. While the disclosed embodiments are not necessarily limited tosuch applications, various aspects of the present disclosure may beappreciated through a discussion of various examples using this context.

In some disclosed embodiments, a system is provided that includes one ormore VoIP servers and a processing circuit, communicatively-coupled tothe one or more VoIP servers, for monitoring data transactions of thecomputing servers. Each of the VoIP servers is configured to providerespective remote services to remote users. The processing circuit isconfigured to monitor data transactions (e.g., VoIP calls and/or voicemessaging accesses) of at least one of the VoIP servers, which isassociated with a user account. A security policy of the user accountincludes a set of conditions that are indicative of unauthorized accesswhen the conditions are satisfied by various characteristics of themonitored data transaction (e.g., frequency of data transactions, sizeof data transaction, files accessed, cost of data transaction, and/orflag in the data packet of the transaction). The processing circuit isconfigured to determine a threat level based on the characteristics ofthe data transactions and the conditions of the security policy. Inresponse to the threat level exceeding a first threshold level indicatedin the security policy of the user account, the processing circuit sendsa notification to an authorized user of the user account.

The threat level may be determined based on a number of differentaspects. For example, in one embodiment, the threat level is determinedbased on a number of the conditions that are satisfied in the securitypolicy. In another embodiment, different conditions of a security policyare associated with respective threat levels. The threat level may bedetermined by determining the highest threat level of the conditionsthat are satisfied by the monitored data transactions. In anotherembodiment, the threat level is determined based on a level ofsensitivity of files/services that are accessed by a data/transaction.In another embodiment, the threat level of data transactions depends onthe direction of the data transactions. For instance, for voice-mailservices provided by a VoIP server, unauthorized downloads of data(e.g., stored voice-mail messages) may pose a larger threat thanunauthorized uploads of data. In contrast, in VoIP call services,unauthorized outgoing calls (which may incur long distance charges) posea larger threat than unauthorized reception of incoming calls (in whichcharges do not apply).

In some embodiments, the processing circuit is further configured tomonitor the data transactions and determine if characteristics of thedata transactions are indicative of a system problem. For instance, insome implementations, characteristics indicative of a system problem mayinclude excessive call jitter, dropped data packets, and/or networkconnectivity. In response to characteristics of the data transactionsbeing indicative of a system problem, the processing circuit sends anotification to the authorized user of the user account and/or to aclient associated with the monitored data transaction that indicated asystem problem. In some implementations, in response to the monitoreddata transactions exhibiting characteristics indicative of a systemproblem, the processing circuit determines if the system problem is aserver-side problem or a user-side problem. In response to determiningthat the system problem is a server-side problem, the processing circuitsends a notification to the authorized user of the user account.Conversely, in response to determining that the system problem is auser-side problem, the processing circuit sends a notification to aremote user corresponding to one of the monitored data transactions thatwas indicative of a system problem.

The processing circuit may provide the notification(s) of possibleunauthorized access and/or system problems using a number of differenttypes of messages. For instance, in some embodiments, the processingcircuit is configured to provide an SMS text message notification to oneor more telephone numbers indicated in the security policy. In someembodiments, the processing circuit is configured to send an automatedvoice call to the telephone number(s). In some embodiments, theprocessing circuit is configured to send an email notification to anemail address indicated in the security policy. In some embodiments,notifications are provided using other messaging services (e.g.,Facebook, My Space, Twitter, and/or Instant Messengers). In someimplementations, multiple notifications are sent to multiple recipientsand/or use multiple types of messages.

In some embodiments, notifications may be provided in real time asinstances of unauthorized access and/or system problems are detected.Some other embodiments avoid generating an overly burdensome number ofnotifications by filtering notifications based on the frequency ornumber of the notifications. For example, one implementation limitsgeneration of notifications to a maximum frequency (e.g., one per hour)that is specified in the security policy. Each notification maysummarize all instances of unauthorized access and/or system problemsthat have occurred since the last notification was sent. As anotherexample, some embodiments limit the number of notifications generatedper day to a number indicated in the security policy.

In some embodiments, the processing circuit is configured to perform afirst set of actions listed in the security policy, in response to thethreat level exceeding a first threshold, to mitigate effects ofunauthorized access. For instance, in response to the threat levelexceeding a threshold, the processing circuit may block one or moreusers or disable one or more remote services provided by the VoIPserver. In some embodiments, the processing circuit may be configured toperform a second set of actions in response to the threat levelexceeding a second threshold. For instance, the processing circuit mayonly alert an account manager in response to the threat level reaching alower threshold and disable the VoIP server in response to the threatlevel reaching a higher threshold.

In one or more embodiments, the notification that is sent to anauthorized user is configured to provide a mechanism for a user toselect from one or more possible actions. For instance, in oneimplementation, an email or SMS text message may include a web addresslink to a webpage from which a user may select an action to take.

In another implementation, a user may select a desired action byresponding to an SMS text message with a text message indicating theselected action.

The security policy may be configured, based on user requirements, toinclude a number of different conditions to detect unauthorized access.For example, some conditions may detect possible unauthorized accessbased on frequency of data transactions. For instance, the securitypolicy may include a condition that indicates unauthorized access mayhave occurred when the frequency of data transactions (e.g., number oftransactions per hour) exceeds a threshold indicated in the securitypolicy. This type of detection may be useful, for example, to detectcall-loops between data carriers. In some implementations, the thresholdis a fixed threshold. In some other implementations, the thresholdadapts based on an average frequency of data transfers. For instance,the condition may be satisfied (indicate unauthorized access) when thefrequency of data transactions surpasses a stored average for theaccount by a threshold amount indicated in the security policy.

As another example, some conditions may detect possible unauthorizedaccess based on the size of the data transactions or total number oftransactions. For instance, the security policy may include a conditionthat indicates unauthorized access may have occurred when the size of adata transaction exceeds a threshold transaction size in the securitypolicy. Similarly, the security policy may include a condition thatindicates unauthorized access may have occurred when a daily datatransfer limit is exceeded. Conditions may place a data transfer limiton each user of a VoIP server or on the total amount of data transferredby a VoIP server.

In some embodiments, one or more conditions may detect possibleunauthorized access based on the location of a user of the VoIP server.For instance, the security policy may include a condition that indicatesunauthorized access may have occurred when a user logs into a monitoredVoIP server from an IP address outside of an IP address rangecorresponding to a block of IP addresses. For example, a condition mayindicate that a user is unauthorized if an IP address of a user isoutside a block of IP addresses used by a company. As another example, acondition may indicate that a user is unauthorized if the IP address ofthe user indicates that the user is located outside of the country.

In some embodiments, possible unauthorized access may be indicated byflags set in one or more data packets of a data transaction. Forinstance, another data carrier may set flags in response to detectingpossible call loops. When the call is forwarded to a VoIP server fromthe other data carrier, the flag can notify the VoIP server of thepossible call loop. The VoIP server can further analyze the call todetermine if a call loop has occurred and/or take remedial measures.

In some embodiments, one or more conditions detect possible unauthorizedaccess using access control mechanisms (passwords, challenge questions,authentication keys). For instance, the security policy may include acondition that indicates unauthorized access may have occurred when anumber of failed login attempts exceeds a limit indicated in thesecurity policy.

The settings of a security policy (e.g., conditions for detectingunauthorized access, threshold levels, and actions to take in responseto a threshold being reached) may be adjusted based on the requirementsof the computing servers that are monitored. In some embodiments, theprocessing circuit is configured to provide a graphical user interface(GUI) that may be used to adjust settings of the security policy.

Turning now to the figures, FIG. 1 shows a telecommunication networkincluding a plurality of computing servers (140, 142, 146), eachconfigured to provide remote services to various end-point devicesincluding, e.g., mobile devices 150, plain-old telephones (POTS) 122,computer(s) 126, IP phones 128. The computing servers may provide avariety of different remote services. In this example, the networkincludes a VoIP server 140, a file server 142, and an application server146 (e.g., virtual machine service). Data transactions related to theremote services are communicated between the computing servers and theremote users over various data networks including, e.g., the internet112, public service telephone networks 102, and private data networks(e.g., LAN 130, WiFi network 124, and/or Private Branch Exchange servers(not shown)).

In this example, the VoIP server 140 is monitored by a processingcircuit(s) (e.g., network monitor 144) which is communicatively-coupledthereto and configured to detect possible unauthorized access of theVoIP server. The communicative-coupling of the VoIP server 140 andnetwork monitor 144 may include either a direct connection or anindirect connection having, e.g., multiple connections, relay nodes,and/or networks in a communication path between the VoIP server 140 andnetwork monitor 144. The network monitor is configured to determine athreat level for the monitored server based on a set of conditions in asecurity polity that are indicative of unauthorized access. In responseto the threat level reaching a threshold level indicated in the securitypolicy, the network monitor sends a threat notification to an authorizeduser (e.g., an account manager) indicated in the security policy. Asindicated above, the network monitor 144 processing circuit may providethe notification of possible unauthorized access using one or moredifferent types of messages including, e.g., SMS text messages, email,voice recording, instant messaging, and/or social network messagingservices.

FIG. 2 shows an alert system configured in accordance with one or moreembodiments of the present disclosure. In this example, the systemincludes a plurality of VoIP servers and a processing circuit (networkmonitor 230) for monitoring data transactions of the VoIP servers. Eachof the VoIP servers is configured to provide respective VoIP services(e.g., VoIP calls, voice messaging, and/or VoIP conferencerecording/transcription) to remote users (e.g., 202 and 204). Datatransactions of the services are communicated between the VoIP servers(222, 224, and 226) and the remote users (202 and 204) over one or morenetworks (e.g., internet 210). As described above, the network monitor230 is configured to monitor data transactions of at least one of thecomputing servers, which is associated with a user account. In thisexample, the network monitor 230 is configured to monitor datatransactions of three VoIP servers (222, 224, and 226). However, invarious embodiments the network monitor may be configured to monitor anynumber of computing servers and/or different types of computing servers(providing different services). The VoIP servers (222, 224, and 226) andnetwork monitor 230 may be implemented as different applications on thesame computing processor, or may be implemented on separate processorsand/or at different locations (e.g., in a cloud computing environment).

As described above, a security policy of the user account includes a setof conditions that are indicative of unauthorized access when theconditions are satisfied by various characteristics of the monitoreddata transaction (e.g., frequency of data transactions, size of datatransaction, files accessed, and cost of data transaction). The networkmonitor is configured to determine a threat level, based on thecharacteristics of the data transactions and the conditions of thesecurity policy. In response to the threat level exceeding a firstthreshold level indicated in the security policy of the user account,the network monitor provides a notification to an account manager (orother authorized user). As discussed with reference to FIG. 1, alertsmay be provided to an account manager using a number of different typesof messages including, e.g., SMS text messages, emails, voicerecordings, instant messengers, and or social network messagingservices.

FIG. 3 shows an example process for monitoring a VoIP server forunauthorized access in accordance with one or more embodiments of thepresent disclosure. In response to a new data transaction 302 to/from aVoIP server, it is first determined whether a security policy isassociated with the corresponding VoIP server. If no security policy isassociated with the VoIP server at decision step 304, the process exits.Otherwise, the process determines if characteristics of the datatransaction satisfy conditions in the security policy at block 308. Asindicated above, the conditions are indicative of possible unauthorizedaccess when satisfied by the characteristics of the data transaction.

If no conditions of the security policy are satisfied at decision step310, the process exits. Otherwise, if one or more conditions of thesecurity policy are satisfied, a threat level is determined at block312. The threat level may be determined based on a number of differentaspects. For example, in one implementation, the threat level isdetermined based on a number of the conditions that are satisfied in thesecurity policy and character. For instance, a larger number ofconditions indicative of unauthorized access that are satisfied mayindicate a greater threat. As another example, different conditions of asecurity policy may be associated with different threat levels. Forinstance, different conditions may have different likelihoods of beingsatisfied. Further, possible adverse effects of the types ofunauthorized accesses indicated by the respective conditions may havediffering levels of severity. In some embodiments, the threat level maybe determined by determining the highest threat level of the conditionsthat are satisfied by the monitored data transactions. In anotherembodiment, the threat level is determined based on an aggregate of thethreat levels of the satisfied conditions. In another embodiment, thethreat level is determined based on a level of sensitivity offiles/services that are accessed by a data/transaction. In anotherembodiment, threat level of data transactions depends on the directionof the data transaction. The threat level may be determined based on acombination of the above and other factors.

If the determined threat level is low enough at decision step 314, suchthat a first threshold of the security policy is not exceeded, theprocess exits. Otherwise, in response to the threat level exceeding thefirst threshold, a notification/alert is provided to an authorized user(e.g., account manager) at block 316. In some embodiments, the processautomatically performs one or more actions in response to the threatlevel exceeding one or more threat levels. For instance, as shown inFIG. 3, in response to the threat level exceeding a second threshold, atdecision block 318, the process performs one or more actions indicatedin the security policy at block 320. In some embodiments, the processmay perform additional actions in response to additional respectivethresholds being exceeded by the determined threat level.

FIG. 4 shows an example process for providing an alert to an authorizeduser of a VoIP server account based on the threat level of theunauthorized access in accordance with one or more embodiments of thepresent disclosure. In response to a threat threshold being exceeded bythe determined threat level 402, an authorized user of the account isnotified at block 404. As indicated above, notification may be performedusing one or more different types of messages including, e.g., SMS textmessages, email, voice recording, instant messaging, and/or socialnetwork messaging services.

In this example, optional actions that may be taken are retrieved fromthe security policy at block 406. The options are presented to a userand the user is prompted to select an action to be taken at block 408.For example, in some embodiments, the notification to the user mayindicate the options and provide a mechanism for the user to select anaction to be taken. For instance, in one implementation, options arepresented in a text message and the desired action is selected byreplying to the text message with one of a plurality of designatedresponses.

In the example shown in FIG. 4, a user is presented with four options(ignore, remove alert, action 1, or action 2). If the ignore option isselected by a user, at decision block 412, the alert is turned off atblock 414 and the process exits. If the remove alert option is selectedby a user, at decision block 416, the condition that triggered the alertis removed from the security policy. This option may be helpful to allowan account manager to use a default security policy and removeunnecessary conditions from the security policy as alerts are triggered.The security policy may also be configured to indicate a number of otheractions (e.g., action 1 and action 2) that may be taken by a user inresponse to different threshold levels being exceeded. If action 1 isselected by a user, at decision block 420, a first action indicated inthe security policy is performed at block 422. Similarly, if action 2 isselected by a user, at decision block 424, a second action indicated inthe security policy is performed at block 426. If no action is selectedby a user, the process exits.

The various embodiments as discussed herein may be implemented using avariety of structures and related operations/functions. For instance,one or more embodiments as described herein may be computer-implementedor computer-assisted, as by being coded as software within a codingsystem as memory-based codes or instructions executed by a computerprocessor, microprocessor, PC or mainframe computer. Such computer-basedimplementations are implemented using one or more programmable circuitsthat include at least one computer-processor and internal/externalmemory and/or registers for data retention and access. One or moreembodiments may also be implemented in various other forms of hardwaresuch as a state machine, programmed into a circuit such as afield-programmable gate array, or implemented using electronic circuitssuch as digital or analog circuits. In addition, various embodiments maybe implemented using a tangible storage medium, which storesinstructions that, when executed by a processor, performs one or more ofthe steps, methods or processes described herein (e.g., the processor isconfigured via the instructions). These applications and embodiments mayalso be used in combination; for instance, certain functions can beimplemented using discrete logic (e.g., a digital circuit) thatgenerates an output that is provided as an input to a processor.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the invention.Based upon the above discussion and illustrations, those skilled in theart will readily recognize that various modifications and changes may bemade without strictly following the exemplary embodiments andapplications illustrated and described herein. For instance, althoughimplementations may in some cases be described in individual figures, itwill be appreciated that features from one figure can be combined withfeatures from another figure even though the combination is notexplicitly shown or explicitly described as a combination. It isintended that the specification and illustrated embodiments beconsidered as examples only, with a true scope of the invention beingindicated by the following claims.

What is claimed is:
 1. A system, comprising: one or more VoIP servers,each configured and arranged to provide respective VoIP services toremote users; and a processing circuit communicatively-coupled to theone or more VoIP servers and configured and arranged to: monitor afrequency of access to the VoIP services on behalf of a particular useraccount corresponding to frequency characteristics indicative ofunauthorized access including at least a call loop; determine a threatlevel as a function of the frequency of the access relative to anaverage frequency of access for the VoIP services; and disable, inresponse to the threat level exceeding a threshold level indicated in asecurity policy of the particular user account, at least one of the VoIPservices for the particular user account.
 2. The system of claim 1,wherein the processing circuit is further configured and arranged todetermine the threat level as a function of a cost of the access to theVoIP services.
 3. The system of claim 1, wherein the threat level is athreat level for the particular user account, and the processing circuitis further configured and arranged to determine the threat level as afunction of whether the accesses to the VoIP services corresponds toinbound or outbound calls relative to the VoIP server.
 4. The system ofclaim 1, wherein the processing circuit is further configured andarranged to determine the threat level as a function of whether theaccesses to the VoIP services include use of voicemail services.
 5. Thesystem of claim 4, wherein the processing circuit is further configuredand arranged to determine the threat level based upon an amount of VoIPcontent that is downloaded from the voicemail services.
 6. The system ofclaim 1, wherein the processing circuit is further configured andarranged to generate a notification to a user indicated in the securitypolicy.
 7. The system of claim 6, wherein the processing circuit isfurther configured and arranged to generate and send multiplenotifications to multiple recipients.
 8. The system of claim 6, whereinthe notification includes selectable options for a recipient of thenotification.
 9. The system of claim 1, wherein the processing circuitis further configured and arranged to determine the threat level basedupon different levels of sensitivity for different VoIP services. 10.The system of claim 1, wherein the processing circuit is furtherconfigured and arranged to: monitor a size of data transactions executedby the particular user account; and determine the threat level as afunction of the size of data transactions executed by the particularuser account relative to a threshold transaction size indicated in thesecurity policy.
 11. The system of claim 10, wherein the processingcircuit is further configured and arranged to determine the threat levelas a function of the size of data transactions executed by theparticular user account relative to a data transfer limit for theparticular user account.
 12. A method for use with one or more VoIPservers that are each configured and arranged to provide respective VoIPservices to remote users, the method comprising: using a processingcircuit communicatively-coupled to the one or more VoIP servers to:monitor a frequency of access to the VoIP services on behalf of aparticular user account corresponding to frequency characteristicsindicative of unauthorized access including at least a call loop;determine a threat level as a function of the frequency of the accessrelative to an average frequency of access for the VoIP services; anddisable, in response to the threat level exceeding a threshold levelindicated in a security policy of the particular user account, at leastone of the VoIP services for the particular user account.
 13. The methodof claim 12, wherein the processing circuit is further configured andarranged to determine the threat level as a function of a cost of theaccess to the VoIP services, and wherein the unauthorized accessincludes access to the VoIP services by an unauthorized internetprotocol (IP) address.
 14. The method of claim 12, further comprisingusing the processing circuit to determine the threat level as a functionof whether the accesses to the VoIP services corresponds to inbound oroutbound calls relative to the VoIP server, and to monitor the frequencyof access for network connectivity problems between the VoIP server andthe remote users.
 15. The method of claim 12, further comprising usingthe processing circuit to determine the threat level as a function ofwhether the accesses to the VoIP services include use of voicemailservices.
 16. The method of claim 15, further comprising using theprocessing circuit to determine the threat level based upon an amount ofVoIP content that is downloaded from the voicemail services.
 17. Themethod of claim 12, further comprising using the processing circuit togenerate a notification to a user indicated in the security policy. 18.The method of claim 17, further comprising using the processing circuitto generate and send multiple notifications to multiple recipients. 19.The method of claim 17, wherein the notification includes selectableoptions for a recipient of the notification.
 20. The method of claim 12,further comprising using the processing circuit to determine the threatlevel based upon different levels of sensitivity for different VoIPservices.